Forum Linux.général Authentification ssh avec deux comptes gitlab.com et deux pairs de clés

Posté par  . Licence CC By‑SA.
1
20
oct.
2019

Hello,

Cela fait 6 jours que je me casse la tête et que je n'arrive pas à gérer deux comptes gitlab.com différents avec deux clés publiques différentes sur le même compte Linux.

Il s'agit bien de deux compte gitlab.com et non de "private gitlab server".

J'ai créé deux pairs de clés dans ~/.ssh et sur chacun des comptes gitlab j'ai poussé la clé publique correspondante.

Cependant lorsque je veux faire un git clone d'un projet sur mon compte gitlab pro je m'aperçois que git utilise la clé ssh pour mon compte gitlab perso.

Je travaille aussi avec L'IDE Intellij sur deux projets différents (un sur chaque compte gitlab) et je suis dans l'impossibilité de commiter sur mon compte gitlab pro depuis 6 jours à cause de ce problème.

J'ai vu énormément de post à ce sujet sur stackoverflow mais aucune des solutions indiquées n'a fonctionné dans mon cas.

Quelqu'un aurait il une solution pour que je puisse travailler sur les deux comptes gitlab sans avoir à changer de compte linux?

Merci pour votre aide

Je suis sur Debian 10 et Intellij 2019

  • # Choix de la clé

    Posté par  (site web personnel) . Évalué à 1.

    Tu devrais regarder du coté de l'agent SSH et comment on fait pour forcer/interdire une clé SSH en particulier.
    En tout cas, ça se fait.

    Bon courage.

    • [^] # Re: Choix de la clé

      Posté par  . Évalué à 1.

      Oui mais ssh-agent est difficile voir impossible à manipuler depuis un IDE (Intellij ou VScode). De plus à chaque appel il c'est un nouveau process qui tourne et qui persiste.

      • [^] # Re: Choix de la clé

        Posté par  (site web personnel) . Évalué à 6.

        Dans la configuration de chaque dépôt : ssh://gitlab1/… ou ssh://gitlab2/…

        Puis dans le fichier ~/.ssh/config :

        Host gitlab1
            Hostname gitlab.com              # le vrai hostname
            IdentityFile ~/.ssh/id_rsa-user1 # vérifier qu'un chemin absolu ne soit pas nécessaire
        
        Host gitlab2
            Hostname gitlab.com              # le vrai hostname
            IdentityFile ~/.ssh/id_rsa-user2 # vérifier qu'un chemin absolu ne soit pas nécessaire
        

        Vérifier avec git fetch dans chaque checkout, et hop.

        Bien évidemment, on peut imaginer des choses plus pertinentes que gitlab1 et gitlab2 d'un point de vue nommage…

        Debian Consultant @ DEBAMAX

        • [^] # Re: Choix de la clé

          Posté par  . Évalué à 1.

          Merci Cyril
          Mais j'ai déjà essayé cette config que j'ai trouvé sur stackoverflow et elle ne fonctionne pas sur ma machine.

              system@notebook:~$ cat ~/.ssh/config 
              Host gitlab-pro
              Hostname gitlab.com
              #Preferredauthentications publickey
              IdentityFile ~/.ssh/keygitlabpro
          
              Host gitlab-perso
              Hostname gitlab.com
              #Preferredauthentications publickey
              IdentityFile ~/.ssh/keygitlabperso
          

          Voici ce que ça donne sur mon poste.

                  system@notebook:~/gitroot/lab/test/test$ git clone 
                  git@gitlab.com:gitlabperso/cloud.git
                  Cloning into 'cloud'...
                  The project you were looking for could not be found.
                  fatal: Could not read from remote repository.
                 Please make sure you have the correct access rights and the repository exists.
                  system@notebook:~/gitroot/lab/test/test$ 
          

          Alors que la même paire de clé déposée sur un autre poste me permet de faire le git clone sans problème et même avec le commande ssh comme ceci.

          $ ssh -i ~/.ssh/keygitlabperso git@gitlab.com
          PTY allocation request failed on channel 0
          Welcome to GitLab, @yourgitlabperso!
          Connection to gitlab.com closed.
          
          

          Je veux bien essayer autre chose si tu as une idée.

          Merci

          • [^] # Re: Choix de la clé

            Posté par  (site web personnel) . Évalué à 1.

            Hello,

            Ça me semble normal : il faut que tu adaptes la configuration lors du git clone ou du git fetch pour utiliser un des paragraphes que tu as ajoutés, sinon c'est la configuration par défaut qui va être utilisée. Dans ton cas, tu peux essayer avec : git clone git@gitlab-perso:gitlabperso/cloud.git

            (Tu pourrais également ajouter le nom d'utilisateur dans la configuration ~/.ssh/config, pour éviter d'avoir à le spécifier dans ta ligne de commande et/ou ton .git/config.)

            Debian Consultant @ DEBAMAX

            • [^] # Re: Choix de la clé

              Posté par  . Évalué à 1.

              Ok Cyril,

              Tu peux m'en dire plus ?
              Comment dois je adapter ma configuration ?

              Tu pourrais également ajouter le nom d'utilisateur dans la configuration ~/.ssh/config

              Est-ce que tu as un exemple ? Sais tu si je dois y mettre l'email de login gitlab ou l'identifiant gitlab au format "@id"?
              Car j'ai déja essayé avec les deux adresses email (celles des deux comptes) mais ça n'a rien donné de plus.

              Je désespère …

              Merci de ton aide

              • [^] # Re: Choix de la clé

                Posté par  (site web personnel) . Évalué à 1.

                Tu peux m'en dire plus ?
                Comment dois je adapter ma configuration ?

                Cf. ma réponse précédente : il faut modifier l'URL que tu utilises dans git clone, ou bien modifier ton .git/config dans un clone existant pour que git fetch utilise l'URL modifiée. Il ne faut plus que ça pointe directement vers github.com mais vers gitlab-perso ou gitlab-pro tel que renseigné dans ton ~/.ssh/config

                J'avais même suggéré une commande à utiliser directement, en me basant sur ta configuration…

                Debian Consultant @ DEBAMAX

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.